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Case 3765 V/ Patent 

Cross-Reference to Related Applications 

This application is related to U.S. Patent No. 5,802,497, entitled METHOD AND 
APPARATUS FOR CONDUCTING COMPUTERIZED COMMERCE, which issued on 
September 1, 1998 and is hereby incorporated by reference herein. 
5 This application is also related to U.S. Patent Application Serial No. 09/081,521, 

entitled METHOD FOR COMMUNICATING SECURE AND AUTHENTICATED 
TRANSACTIONS OVER AN NON-SECURE NETWORK SUBJECT TO EXPORT 
RESTRICTIONS, which was filed on May 19, 1998, and is hereby incorporated by 
reference herein. 

10 This application is also related to U.S. Patent Application Serial No. <Attorney 

Docket 3763>, entitled ENCRYPTING SECRETSIN^Ajai^^ 
MICRO^QQMMEReE-S Y S 1 EMTwhich was filed on the same date as the instant 
application. 

15 Background 

Field of the Invention 

This invention relates generally to an electronic commerce system and more 
particularly to providing refunds while maintaining relative anonymity in the system. 

20 Background of the Invention 

With the advent of electronic forms of communication, including telegraph, 
telephone, radio, television, and more recently digital networks, it has become possible to 
conduct commerce electronically using digital computer systems. Electronically encoded 
funds are different than physical currency in that it is a trivial matter to duplicate 

25 electronic representations of funds. One of the difficult tasks faced in conducting 
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computerized commerce is to detect the illegal re-use of electronic funds, e.g., double 
spending. 

Known electronic fund transfer systems generally require a "trusted" third party 
between mS>etidor and consumer to authenticate the validity of the electronic funds. 



term relationship between the vendor and consumer, either through-a-suhscription-service 
or by billing accounts as are provided by credit card organizations. These methods are 
efficient at handling transaction requests, assuming a reasonable authentication scheme. 
However, these methods require a prior effort to establish an "account" or other evidence 
15 of credit worthiness. For a large number of consumers, e.g. all potential users of a large 
network of computers like the Internet, setting up accounts and maintaining credit 
information adds prohibitive expense to the vendors, and inconvenience and impediments 
to the consumers. 



20 Internet, has accelerated the need for a low-cost computerized electronic commerce 
system. In addition, in the information marketplace there is a particular need to 
economically support transactions that are for amounts as small as a hundredth of a cent. 

U.S. Patent No. 5,802,497 (the '497 patent) describes a lightweight and secure 
protocol for electronic commerce over the Internet. The protocol is designed to support 

25 purchases costing less than a cent. The system is based on decentralized validation of 
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Alternative methods of electronic fund transactions involve establishing a long- 



The recent growth of public access communications networks, such as the 
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electronic cash at a vendor's server without any additional communication, expensive 

encryption, or off-line processing. 

Two innovations in the '497 patent are its use of brokers and scrip. Brokers take 

care of account management, billing, connection maintenance, and establishing accounts 
5 with vendors. Scrip is digital cash that is valid for only a specific vendor. The vendor 

locally validates the scrip to prevent customer fraud, such as double spending. 

Every time a user visits a new vendor, the user must get scrip for that vendor from 

a broker. Scrip is held and manipulated by the user using an application called a Pallet." 

The wallet includes scrip with each request to purchase content and gets back change 
1 0 from the vendor with the returned content. 

Occasionally, the consumer may want to get a refund for scrip. Perhaps the 

consumer did not like the received content, or the transaction failed, or the consumer 

merely wants to convert the vendor scrip back into broker scrip. The '497 patent does not 

describe a mechanism for such refunds. 
15 Refunds can be divided into two classes: safe and potentially fraudulent. A safe 

refiind^s ^conyersion of unspent vendor scrip back into broker scrip . There is no 

question of fraud and if there is any cost for the refund, it is deducted as a fee from the 

refund. In this case, the vendor should perform the refund without requiring any 

additional information about the consumer's identity. 
20 A potentially fraudulent refund occurs when a consumer asks for a refund for 

spent scrip resulting from a failed transaction or unacceptable product. While there is no 

reason for a vendor to need the identity of the consumer for a regular transaction or a safe 

refund, a vendor may want to identify consumers seeking potentially fraudulent refunds. 

Only by tracking all refund requests and noticing patterns of abuse by specific consumers 
25 can vendors detect and prevent fraud. 
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Thus, a refund mechanism should balance the consumers' desire for anonymity 
while making purchases with the vendor's desire to identify consumers who ask for 
potentially fraudulent refunds. The refund mechanism should also allow the vendor to 
validate the identity information from the consumers without needing additional storage 
or communication with the broker. 

Moreover, a vendor might have multiple brokers issuing its scrip. If the consumer 
gets a refund for a specific piece of scrip, the refund should be issued for the broker that 
either directly sold the scrip, or sold the scrip from which the scrip was derived. 

Furthermore, the refunded broker scrip and any scrip derived from it should be as 
secure as scrip purchased directly from the broker. The vendor should not be able to 
spend the refunded broker scrip or any scrip subsequently derived from it. 



Summary of the Invention 

The above needs are met by a method and system for electronic commerce that 
provides relativfe^nonymity for regular purchases but optionally allows the vendor to 
quickly and easily vern^Nt|ie identity of a consumer seeking a refund. The system 
includes a broker computer system having a database of broker scrips, each vendor scri p 
representin g a form of electronic currehqy . The system also includes a vendor computer 
system having a database containing produc^swhich may be exchanged for the vendor 
scrips, the vendor computer system capable of prcm<hng vendor scrips. In addition, the 
system includes a consumer computer system having a u^sr interface whereby a 
consumer may initiate transactions in the consumer computer system to obtain one or 
more of the products contained in the database of the vendor computer system. 

Each piece of scrip has ji_yalue, which may range from a few dollars to a few 
hundredths of a cent. In addition, each piece of scrip has a Customer ID from which a 
customer secret (CS) is derived. The broker and the vendor share and maintain a master 
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customer secrets (MCS) table indexed, by bits of the Customer ID. When a broker (or 
vendor) issues scrip to the consumer, the broker hashes the Customer ID with the MCS 
specified in the table to form the CS. A preferred embodiment of the present invention 
uses the HMAC-MD5 algorithm for hashing. The CS is sent to the consumer with the 
5 associated piece of scrip. The consumer holds the scrip and its associated CS in a 
database called a "wallet" and uses the CS to prove that the consumer has the right to 
spend the associated scrip. 

In addition, the Customer ED field of a scrip has a Hash subfield. When the 
consumer makes the initial scrip purchase from a broker, the consumer and/or the wallet 
10 provide the broker with unique identifying information. The broker hashes this 

identifying information with a first nonce — a unique string of arbitrary length generated 
by the broker — and stores the resulting hash in the Hash subfield. The broker provides 
the first nonce to the consumer and the consumer stores the nonce in the wallet. 



1 5 the consumer exchanges broker scrip for vendor scrip), the value of the Hash subfield of 
the original scrip is hashed with another nonce to form the Hash subfield for the new 
scrip. For example, assume a consumer buys broker 2 scrip from a first broker, and then 
uses the broker 2 scrip to buy vendor scrip from a second broker. The Hash subfield of 
the broker 1 scrip is the hash of the identifying information with a first nonce. The Hash 

20 subfield of the broker 2 scrip is the Hash subfield of the broker 1 scrip hashed with a 
second nonce. The Hash subfield of the vendor scrip, in turn, is the hash of the Hash 
subfield of the broker 2 scrip with a third nonce. The consumer stores all three nonces 
(for the broker 1 scrip, the broker 2 scrip, and the vendor scrip) in the wallet. 



25 vendor and that the vendor desires to authenticate the identity of the consumer. In this 



When scrip is used to buy scrip with a different Customer ID (for instance, when 



Assume that the consumer wants to get a refund for the vendor scrip from the 



case, the consumer provides the vendor with the vendor scrip, the unique identifying 
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information, and the chain of nonces used to form the Hash subfield of the scrip. The 
vendor hashes the nonces with the identifying information and attempts to recreate the 
value stored in the Hash subfield of the scrip for which the consumer seeks the refund. If 
the recreated value matches the Hash subfield, then the consumer has provided the vendor 
5 with the correct identifying information. 

If the vendor does not need to authenticate the identity of the consumer, the 
consumer does not provide the nonce and identity information. The vendor automatically 
approves the refund without verifying and logging the consumer's identity. 

In response, the vendor preferably issues the consumer a refund coupon having 

10 the same Customer ID as the scrip being refunded. Preferably, the refund coupon is 
issued from a special scrip series for the broker who issued the vendor scrip. Then, the 
consumer provides the refund coupon to the broker, along with the Customer ID of the 
broker scrip used to purchase the vendor's scrip. In response, the broker issues the 
consumer new broker scrip having the provided customer ID. The consumer can use this 

1 5 new broker scrip to seek a cash refund or buy new vendor scrip. 



Brief Description of the Drawings 



FIGURE 1 is a top-level block diagram illustrating a computerized system for 



conducting electronic commerce; 



20 



FIGURE 2 is a block diagram illustrating a computer system used in the system of 



FIG. 1; 



FIGURE 3 is a flow diagram illustrating the operations of the system of FIG. 1; 



FIGURE 3 A is a flow chart illustrating certain operations depicted in FIG. 3; 



FIGURE 3B is a flow chart illustrating other operations depicted in FIG. 3; 



25 



FIGURE 4 is a block diagram illustrating the data fields of a piece of scrip used in 



the system of FIG. 1; 
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FIGURE 5 is a block diagram illustrating a more detailed view of the Customer 
ID field of the scrip of FIG. 4; 

FIGURE 6 is a flow diagram illustrating the interactions between a consumer, two 
brokers, and a vendor when the consumer purchases product from the vendor; and 
5 FIGURE 7 is a flow diagram illustrating the interactions between the consumer, 

the two brokers, and the vendor when the consumer obtains a refund according to an 
embodiment of the present invention. 



Detailed Description of the Preferred Embodiments 

10 FIG. 1 shows a computerized system 100 for conducting electronic commerce 

according to the principles of the invention. The system 100 includes a broker system 
1 10, a vendor system 120, and a consumer system 130 interconnected by a 
communications network 140. 

For clarity, the system 100 depicted in FIG. 1 shows only single broker, vendor, 

1 5 and consumer systems. In actual practice, any number of broker, vendor, and consumer 
systems can be interconnected by the network 140. 

The broker 111 using the broker system 110 can be a bank, a credit provider, an 
Internet service provider, a telephone company, or any institution the consumer trusts to 
sell scrip. The vendor system 120 is operated by a vendor 121. The vendor 121 provides 

20 products 150 of any type to consumers. 

A consumer 131 can use the consumer computer system 130 to "electronically" 
acquire the products 150 of the vendor 121. The network 140 can be public or private, 
such as, for example, the Internet, a switched telephone system, a satellite linked network, 
or another form of network. 

25 A computer system 200 suitable for use as the broker, vendor, and consumer 

systems is shown in FIG. 2. The computer system 200 includes a central processing unit 
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(CPU) 210, a memory 220, and an input/output interface 230 connected to each other by 
a communications bus 240. The CPU 210, at the direction of users 250, e.g. brokers, 
vendors, and/or consumers, executes software programs for manipulating data. The 
programs and data can be stored in the memory 220 as a database (DB) 221 . The DB 221 
5 storing programs and data on the consumer computer system 130 is referred to as a 
"wallet." 

The memory 220 can include volatile semiconductor memory as well as persistent 
storage media, such as disks. The I/O interface 230 is for communicating data with the 
network 140, the users 250, and other computer system peripheral equipment, such as 

10 printers, tapes, etc. 

The computer system 200 is scaled in size to function as the broker, vendor, or 
consumer systems. For example, when scaled as the consumer computer system 130, the 
computer system 200 can be a small personal computer (PC), fixed or portable. The 
configurations of the computer system 200 suitable for use by the broker 1 1 1 and the 

15 vendor 121 may include multiple processors and large database equipped with "fail-safe" 
features. The fail-safe features ensure that the database 221 is securely maintained for 
long periods of time. 

FIG. 3 and FIG. 3 A show an operation of the system 100 according to a preferred 
embodiment of the invention. The consumer 131 in step 3015 uses currency to purchase 

20 electronic broker scrip 320 generated in step 30 1 0 by the broker 111. Here, purchasing 
means that upon a validation of the authenticity of the consumer 131 and the consumer's 
currency 310, the broker system 1 10 generates signals, in the form of data records. The 
signals in step 3020 are communicated, via the network 140, to the consumer system 130 
for storage in the wallet 221 of the memory 220 of the consumer system 130. 

25 The currency 310 which is exchanged for scrip 320 can be cash, check, credit 

card, bank ATM card, debit card, phone card, or other items of value. The scrip 320 can 
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also be freely exchanged with "coupons" frequently used in promotional schemes. The 
"coupons" can be in form of the scrip. 

The scrip is described in further detail below. In brief, the scrip is stamped by the 
generator of the scrip. This means that the scrip carries information that is verifiable by 
5 only the originator. In addition, each scrip is uniquely identifiable. After a single use, 
the originator of the scrip can "invalidate it," meaning that the signals of the data record 
are no longer accepted for processing by the originating computer system. 

Preferably, the broker system 1 10 in step 3027 executes licensed software 
programs which generate vendor scrip 330 for the consumer 131 as needed. In this case, 

10 the "value" of the license can be proportional to the amount of scrip that the licensee can 
generate. Alternatively, the broker 1 1 1, in a similar transaction 303, exchanges currency 
310 for bulk electronic vendor scrip 330 in step 3030 and 3035. The vendor scrip 330 is 
generated in step 3025 by the vendor system 120. As will be described below, the scrip 
can have an expiration date so that the issuer does not forever need to maintain data 

1 5 regarding the issued scrip. 

The consumer 131 desiring the products 150 provided by the vendor 121, can 
exchange 3040, 3045, 302 the broker scrip 320 for vendor scrip 330, and then exchange 
the vendor scrip for products 150. If the purchase price of the product 150 is less than the 
value of the vendor scrip 330, new vendor scrip can be issued for the balance as 

20 "change." As described in more detail below, a separate transaction type allows 
consumers 131 to ask vendors 121 and brokers 1 1 1 to refund scrip. 

In an alternative embodiment shown in FIG. 3, FIG. 3A and FIG. 3B, the 
consumer 131 can establish an "account" with the vendor 121 to acquire vendor scrip 330 
directly, without the need of a third party broker as indicated in steps 3055 and 3060. 

25 Establishing an account means that an account data record is maintained in the vendor 
computer system 120. 
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The consumer 131, in a transaction 304, submits in step 3045, the vendor scrip 
330 to the vendor 121. The vendor 121 checks the stamp of the vendor scrip 330 to 
verify its authenticity, and to validate the "currency" amount. Verification also checks 
the local database to determine whether the scrip is previously spent. Approval of the 
5 transaction 303 results in the delivery of the desired product 150 to the consumer 131 in 
step 3050. In the transaction 304, change can also be returned to the consumer 131 in the 
form of vendor scrip having a value which is the amount of the over-payment, e.g., 
another data record communicated by the network 140. 

The broker selling the initial scrip to the consumer normally knows the identity of 

10 the consumer. In addition, when a consumer buys scrip from a either a primary or 
secondary broker, the broker knows for which of its vendors or other brokers the 
consumer purchases scrip. Furthermore, each vendor knows the specific items the 
consumer is purchasing from the vendor. However, without either completely observing 
the consumer's requests, or merging records, no single entity knows the full purchase 

1 5 history of the consumer. 

Thus, the vendor 121 does not know — and cannot normally determine — the 
identity of the consumer 131. The vendor 121 needs to ensure only that valid vendor 
scrip 330 is being exchanged for products 150. In other words, the databases of the 
broker, vendor, and consumer are separately and securely maintained, using methods and 

20 systems for protecting networks, computer systems, and databases that are known in the 
art. 

The electronic signals which represent the scrip, and which are processed and 
communicated by the system 100 are described with reference to FIG. 4. FIG. 4 is a 
block diagram illustrating the data fields of a single piece of scrip 400 according to one 
25 embodiment of the present invention. The scrip 400 is logically separated into seven data 
fields. The Vendor field 410 identifies the vendor for the scrip 400. The Value field 412 
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gives the value of the scrip 400. The script ID field 414 is the unique identifier of the 
scrip. The Customer ID field 416 is used by the broker 1 1 1 and vendor 121 to determine 
the customer secret (CS) for the scrip and holds additional information supporting refund 
processing as described below. A portion of the Customer ID field 416 forms the 
5 Customer ID partition number. The Expires field 418 gives the expiration time for the 
scrip 400. The Props field 420 holds customer properties, such as the customer age, state 
of residence, etc. Finally, the Stamp field 422 holds a digital signature and is used to 
detect tampering of the scrip 400. 

In a preferred embodiment of the present invention, the broker 111 and vendor 
10 121 share a Master Customer Secret (MCS) table indexed by the partition number of the 
Customer ID field 416. Thus, the MCS table is as follows: 
MCS Table: 



Partition Number 


Master Customer Secrets 




MCS, 




MCS 2 




MCS 3 



Both the partition numbers and the MCS are preferably binary strings having lengths and 

1 5 values agreed to by the broker 111 and the vendor 121 . 

When the consumer 131 buys scrip 400 from the broker 111 (or receives scrip 
from a vendor 121), the broker 1 1 1 generates the CS for the scrip 400 by determining the 
partition number from the Customer ID field 416 and looking up the corresponding MCS 
in the MCS table. Then, the broker 1 1 1 calculates the CS from a hash of the customer ED 

20 with the MCS: 

CS = H(customer ID, MCS), 
where H() denotes a hash function. In one embodiment, the hash function used 
throughout the electronic commerce system is HMAC-MD5, described in H. Krawczyk, 
M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication " RFC 
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2104, February 1997, and R. Rivest, "The MD5 Message Digest Algorithm," RFC 1321, 
April 1992, both of which are hereby incorporated by reference herein. However, any 
suitably secure one-way hash function can be substituted. 

If this is the first piece of scrip purchased by the consumer 131 from the broker 
5 1 1 1 , the CS is provided to the consumer 1 3 1 via a secure channel and the consumer 131 
stores the CS in the wallet 221. A preferred secure channel is described in U.S. Patent 
Application Serial No. 09/081,521, entitled METHOD FOR COMMUNICATING 
SECURE AND AUTHENTICATED TRANSACTIONS OVER AN NON-SECURE 
NETWORK SUBJECT TO EXPORT RESTRICTIONS, which was filed on May 19, 

10 1998, and is hereby incorporated by reference herein. 

If the consumer 131 has already received a CS from the broker 1 1 1, the broker 
1 1 1 uses the previously provided CS (the old CS, or OCS) to transmit a new CS (NCS) to 
the consumer 131 without requiring a secure channel. The broker 111 calculates the NCS 
using the Customer ID field 416 and the corresponding MCS in the MCS table in the 

15 same manner that the OCS was calculated. Then, the broker 1 1 1 calculates a result as 
follows: 

result = NCS XOR H(nonce, OCS), 
where "XOR" is the exclusive-or function and a nonce is a random, guaranteed unique 
string of arbitrary length. The result and the nonce are passed to the consumer 131. 

20 When the consumer 131 receives the result and nonce, the consumer 131 derives 

the NCS by performing the calculation: 

NCS = result XOR H(nonce, OCS). 
The consumer 131 preferably stores the NCS with the corresponding scrip 400 in the 
wallet 221. Thus, the broker 111 communicates the value of the NCS to the consumer 

25 131 without actually transmitting the NCS in the clear. The consumer 131 uses the CS to 
prove ownership of, i.e., possession of the right to spend, the scrip. 
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In a preferred embodiment of the present invention, the consumer 131 requests 
product from the vendor 121 in the context of the World Wide Web (WWW). However, 
the present invention can be used for purchases in any electronic context. Accordingly, 
the request is phrased as a uniform resource locator (URL) pointing to a location at a 
5 vendor-controlled domain. 

To spend scrip 400 for a product, the consumer 131 sends the vendor 121 a 
message in the form: 

scrip, request, H(scrip, request, CS), 
where scrip is the vendor scrip 400 issued to the consumer, the request is the URL 
10 specifying the requested product, and H(scrip, request, CS) is a hash of the scrip, request, 
and the CS. Thus, the consumer 131 sends the scrip in the clear (unencrypted). 

When the vendor 121 receives the scrip 400, the vendor 121 first validates the 
Stamp field 422 to ensure that the scrip 400 was not altered. Next, the vendor 121 
validates that the consumer 131 possesses the correct CS. This validation is performed 
15 by extracting the partition number from the Customer ID field 416 of the received scrip 
and looking up the corresponding MCS in the MCS table held in the database 221. Then, 
the vendor recreates the CS by calculating CS = H(Customer ID, MCS). Using the 
recreated CS, the vendor 121 calculates the request stamp H(scrip, request, CS). If the 
calculated request stamp matches the request stamp supplied by the consumer 131, then 
20 the vendor 121 has a high degree of confidence that the scrip 400 was received from 
someone knowing the CS. 

Once the vendor 121 has validated the scrip 400 and consumer 131, the vendor 
preferably provides the requested product to the consumer 131. Also, the vendor 121 
may issue scrip to the consumer 131 as change by using the techniques described above. 
25 For normal purchases, as described above, the knowledge of secrets follows a 

defined trust relationship. It is acceptable for brokers 1 1 1 to know the customer secrets 
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for vendor 121 scrip because the brokers 1 1 1 are trustworthy. Vendors 121 know the 
customer secrets for scrip they validate or produce. Also, consumers 131 know the 
customer secrets for only the scrip they own. 

When a vendor 121 issues a refund, it reverses the normal broker- vendor- 
5 consumer flow of trust. A vendor 121 produces refund scrip in the name of the broker 
111, even though vendors 121 are not assumed to be totally trustworthy. Furthermore, if 
the vendor produces the refund as regular broker scrip, then the vendor 121 knows the CS 
for the resulting broker scrip. If that broker scrip were used to buy vendor scrip for 
another vendor 121, the refunding vendor 121 could know the customer secret for the 
10 new scrip if the vendor could eavesdrop on the consumer's transactions at the broker 111. 
However, as indicated by the trust relationship, it is unsafe for vendors to know the CS of 
other vendors' scrip. 

Accordingly, the present invention provides refunds without violating the trust 
relationship defined above. FIG. 5 illustrates a more detailed view of the Customer ID 
15 field 416 of FIG. 4 according to a preferred embodiment of the present invention. The 
Customer ID field 416 has three subfields: Mtoken 510, Expiration 512, and Hash 514. 
There is also a nonce associated with the Customer ID field 416 which is communicated 
along with the scrip, but, for privacy reasons, is not directly included in the scrip. The 
Mtoken subfield 510 holds the Customer ID partition number described above with 
20 which a broker 1 1 1 and a vendor 121 (or two brokers) use to index to the shared MSC 
table. In addition, the Mtoken subfield 510 may hold additional information identifying 
the CS, such as a serial number. 

The Expiration subfield 512 indicates the latest date on which any scrip generated 
with this customer ID can be used to obtain a refund. The expiration date is preferably 
25 chosen from a restricted set, such as a month or day boundary. If the expiration date was 
too specific, it could act as a de-facto ED for that consumer and could inadvertently tie 
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together otherwise unrelated purchases by the consumer 131. In addition, since the 
Expiration sub field 512 is the expiration date for refunding the scrip, and the Expires 
field 418 is the expiration date for spending the scrip, it is likely that the two dates will be 
different. 



identifying the consumer 131 or wallet 221 and a nonce. Thus, the Hash subfield 514 of 
the first piece of broker scrip holds the value: 
hash! = H(nonce l5 1). 

Only the first broker is given the identity value, I. After that, other brokers and vendors 
10 are given hash values derived from I. When the first broker generates scrip for a vendor 
or a second broker, the first broker 111 chooses a new nonce, nonce 2 , and generates the 
hash: 

hash 2 = H(hash 1? nonce 2 ). 
More generally, the Hash subfield 514 holds the value: 



where h, is the identifying value I, h^, is a hash, and is a nonce. 

In one embodiment, the unique identifying value I is supplied by the consumer 
131 and/or the wallet 221. In another embodiment, the consumer 131 provides some 
information and the wallet 221 appends additional information. For example, the unique 
20 value I may be an email address, a pass phrase, a name, or a broker-assigned ID number 
supplied by the consumer 131, and a short text string supplied by the wallet. In an 
alternative embodiment, the wallet supplies the entire identifying value. This alternative 
may be preferred because it does not require the consumer 131 to memorize and recall 
information. 

25 In a preferred embodiment of the present invention, the unique value I includes a 

predetermined string and is not merely a random string. For example, in one embodiment 
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The Hash subfield 514 holds a value derived from the hash of a value, I, uniquely 
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the wallet-supplied value is a random number appended to the string "WID" If the 
unique value were merely a random string, a malicious consumer or malicious wallet 
could make the unique number a string that is an intermediate result of a sequence of 
hashes. As is described below, the malicious wallet could obscure its identity by 
5 presenting vendors or brokers with different hashes in the sequence. Since it is difficult 
to derive an intermediate hash result having a particular value, including the 
predetermined string helps to defeat this type of attack. 

Each time a broker 1 1 1 or vendor 121 uses a new nonce to create a hash in the 
Hash sub field 514, the broker 1 1 1 or vendor 121 supplies the nonce to the wallet 221 . 

10 The wallet 221 stores the nonces apart from the scrip, but maintains the associations 
between the nonces and the scrip. Thus, the wallet 221 can provide the chain of nonces 
that were used to create a particular hash value. 

FIG. 6 is a flow diagram illustrating the interactions between a consumer 610, two 
brokers respectively called broker 1612 and broker 2 614, and a vendor 616 when the 

1 5 consumer 610 purchases product from the vendor 616. In the illustrated example, broker 
1612 sells broker scrip for itself and for broker 2 614. Broker 2 614, in turn, sells vendor 
scrip for the vendor 616. Note that the interactions performed by the consumer 610 may 
be automatically performed by the wallet 221 . 

First, the consumer 610 purchases 617 broker 1 scrip from broker 1612. The 

20 consumer may pay for this purchase with real money (e.g., cash or a credit card). The 
consumer also provides broker 1612 with identifying information I„ which uniquely 
identifies the consumer 610. In return, broker 1 hashes Ij with a nonce, nonce,, and stores 
the resulting hash value, hash l5 in the Hash subfield 514 of the broker 1 scrip, thereby 
forming customer ID,. Broker 1 612 issues 618 the broker 1 scrip having customer ID! to 

25 the consumer 610 along with nonces 
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The consumer 610 uses the broker 1 scrip to purchase 620 broker 2 scrip from 
broker 1614. Broker 1 calculates hash 2 = H(hash„ nonce 2 ) and places the result in the 
Hash subfield 514 of the broker 2 scrip, thereby forming Customer ID 2 . The broker 2 
scrip and nonce 2 are sent 622 to the consumer 610 and stored in the wallet 221. 
5 The consumer 610 uses the broker 2 scrip to purchase 624 vendor scrip from 

broker 2. Broker 2 calculates hash 3 = H(hash 2 , nonce 3 ) and places the result in the Hash 
subfield 514 of the vendor scrip, thereby forming Customer ID 3 . The vendor scrip and 
nonce 3 are sent 626 to the consumer 610 and stored in the wallet 221. 

Then, the consumer 610 uses the vendor scrip to purchase 628 product from the 
10 vendor 616. The vendor 616 provides 630 the product to the consumer 610, along with 
any change that the consumer 610 is due. 

Suppose, however, that the consumer 610 never receives the product, or that the 
consumer is unhappy with the product, and wishes to obtain a refund for the spent scrip, 
or that the consumer merely wants to get a refund for unspent scrip. FIG. 7 is a flow 
15 diagram illustrating the interactions between the consumer 610, the two brokers 612, 614, 
and the vendor 616 when obtaining a refund according to an embodiment of the present 
invention. 

The consumer 610 requests 710 a refund coupon from the vendor 616. In one 
embodiment, the consumer 610 makes this request by visiting a location at the vendor's 

20 616 web site identified by a reserved uniform resource locator (URL) and providing the 
scrip for which the consumer seeks the refund (i.e., the vendor scrip spent to purchase the 
product or vendor scrip that the consumer does not want to spend). At this point, assume 
the vendor 616 wishes to verify the identity of the consumer 610 in order to detect fraud. 
Accordingly, the vendor 616 requests that the consumer and/or wallet provide 

25 identification information I 2 and the series of nonces that were used to create the value of 
the Hash subfield 514 of the scrip for which the consumer 610 seeks a refund. Then, the 
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vendor uses the identifying information I 2 and the series of nonces to produce 712 a new 
hash value as follows: 

a = H(I 2 , nonce,); 

b = H(a, nonce 2 ); and 
5 c = H(b, nonce 3 ). 

If c is equal to the value in the Hash subfield 514 of the vendor scrip, then identifying 
information I 2 equals the identifying information I, and the vendor 616 has verified the 
identity of the consumer 610 seeking the refund. 

Accordingly, the vendor 616 issues 714 a refund coupon to the consumer 714. 
10 The coupon has customer ID 3 , the same customer ID as the scrip being refunded. In one 
embodiment, the refund coupon is scrip issued from a special series at the vendor's 
broker 614 reserved for the vendor's refund coupons. Because broker 2 614 is the same 
broker that issued the initial vendor scrip to the user, broker 2 614 knows the shared MCS 
associated with customer ID 3 . 
15 The consumer 610 supplies 716 the refund coupon to broker 2 614 along with 

Customer ID 2 , the customer ID of the broker scrip the consumer 610 used to buy the 
vendor scrip. 

In turn, broker 2 returns 718 new broker 2 scrip having customer ID 2 , the 
customer ID of the consumer's original broker 2 scrip. The wallet 221 remembers the CS 

20 associated with this scrip from when it first received scrip with customer ID 2 . Broker 2, 
of course, already knows the MCS for the scrip having customer ID 2 . Since every 
customer ID partition has a different MCS, the vendor 616 will not know the MCS for 
customer ID 2 . Therefore, the vendor 616 cannot interfere with future transactions derived 
from the refunded scrip. Although not illustrated in FIG. 7, the consumer 610 can 

25 continue the refund back up the chain of brokers. The refunded broker 2 scrip can be 
refunded by broker 2 614 into a broker 1 refund coupon and the broker 1 refund coupon 
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can be exchanged at broker 1 612 for broker 1 scrip with customer TD { . Likewise, the 
consumer 610 can seek a cash refund for the broker 1 scrip from broker 1 612. 

The vendor 616 does not always need to validate the consumer's identity to issue 
a refund. The consumer may not be asking for a refund to settle a problem with spent 
5 scrip, but merely be asking for a refund of unspent scrip. The refund mechanism is the 
same in this case, except that the consumer does not include I 2 and the nonces with the 
refund request, and the vendor 616 does not verify the Hash subfield 514 of the scrip 
before issuing the refund coupon. 

In this case, the refund is made without the consumer 610 revealing any additional 

10 identity information to the vendor 616. The vendor 616 issues a broker 2 refund coupon 
containing the vendor's customer ID. Broker 2 614 converts the refund coupon into 
ordinary broker 2 scrip with broker 2's customer ID. Since the vendor 616 never sees I, 
the nonces, or broker 2's customer ID, the vendor 616 does not learn any additional 
information about the consumer 610 during the refund. 

15 Accordingly, the present invention provides relative consumer anonymity while 

making purchases and making unverified refunds, but allows the vendor to easily verify 
the consumer's identity — if necessary to prevent fraud — before issuing a refund. This 
verification requires no extra storage at the vendor and minimal storage in the consumer's 
wallet. 

20 In addition, the present invention maintains the trust agreement between the 

parties. The refunded scrip from the broker uses the original customer ID of the 
consumer's broker scrip. The vendor does not know the MCS for that customer ID, so 
the vendor cannot know the CS. Since the consumer must present a refund coupon to the 
broker before obtaining a refund, and the refund coupon has an identifier that marks the 

25 coupon as being issued by a specific vendor, the broker knows exactly which vendor 

provided the refund. Moreover, the refund coupon bears a customer ID that comes from a 
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series of customer IDs issued by the broker for that vendor. Thus, the broker can return 
broker scrip to the consumer, knowing that the refund is related to scrip the consumer 
purchased from the vendor. The consumer, in turn, already knows the CS for the 
customer ID in the scrip. 

Having described a preferred embodiment of the invention, it will now become 
apparent to those skilled in the art that other embodiments incorporating its concepts may 
be provided. It is felt therefore, that this invention should not be limited to the disclosed 
invention, but should be limited only by the spirit and scope of the appended claims. 
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